Направо към съдържанието

Spring Framework

от Уикипедия, свободната енциклопедия
Spring Framework
Информация
РазработчикPivotal Software
Начална версия1 октомври 2002 г.;
преди 22 години (2002-10-01)
Последна версия4.1.5[1]
Програмен езикJava (programming language)
Операционна системаCross-platform
ПлатформаJava Virtual Machine
СтатусActive
Вид софтуерApplication framework
ЛицензApache License 2.0
Уебсайтspring.io
Spring Framework в Общомедия

Spring Framework е технологична рамка (framework) с отворен код (open source) за Java платформата. Spring framework предоставя много функции, които улесняват разработването на Java-базирани enterprise приложения.

Модули

[редактиране | редактиране на кода]

Spring Framework включва различни модули, които предоставят широк набор от функционалности:

Контейнер на зависимостите (инжектор)

[редактиране | редактиране на кода]

Основното ядро в Spring Framework е неговият IoC (Inversion of Control) контейнер, който осигурява логически средства за конфигуриране и управление на Java обекти с помощта на reflection. Контейнерът е отговорен за управлението на жизнения цикъл на специфични обекти: създаването на тези обекти, извикването на инициализиращите им методи и конфигурирането им свързвайки ги заедно. Обектите, създадени от контейнера се наричат още управлявани обекти или бийнове (beans). Контейнерът може да бъде конфигуриран чрез зареждане на XML файлове или засичането на специфични Java анотации от конфигуриращите класове.

Обектите могат да бъдат получени чрез dependency lookup или dependency injection. Dependency injection е софтуерен шаблон за дизайн, който опростява обектно ориентираното програмиране (ООП) чрез намаляване на зависимостите между отделните класове. Така при създаването на един проект, използвайки някой обектно ориентиран език се избягва зависимостта от конкретни имплементации, и се набляга повече на абстракции. Това се нарича още обръщане на контрола (inversion of control) – когато модулите от високо ниво не зависят от модули от по-ниско ниво.

При dependency injection обектите се проектират по начин, при който те получават инстанции на обекти от различен външен модул код, вместо да са конструирани вътре в него. Dependency injection включва най-общо три елемента:

  • зависим елемент;
  • декларация на зависимостите на елемента, дефинирани като интерфейси, абстрактни класове;
  • контейнер на зависимостите (инжектор), който създава инстанции на класове, които реализират дадена интерфейсна зависимост при заявка.

Зависимият елемент определя на какъв софтуерен компонент зависи за да си свърши работата, а контейнерът решава какви конкретни класове отговарят на изискванията на зависимия обект, и ги предоставя като зависимости. По този начин контейнерът по свой избор, може да променя конкретните имплементации, които се използват по време на изпълнение на програмата (run-time), а не по време на компилация (compile-time). По време на изпълнение (run-time) могат да бъдат създадени множество различни инстанции на даден софтуерен компонент, без значение, каква конкретна е била инжектирана.

Това позволява кодът, който пишем да е много по модуларен и разкачен, което го прави в същото време и много по-тестваем.

Аспектно-ориентираното програмиране (АОП)

[редактиране | редактиране на кода]

Аспектно-ориентираното програмиране (АОП) е относително нова парадигма в програмирането която цели да се увеличи модулността на софтуера и включва методи и инструменти които помагат за това.

Почти всички програмни парадигми поддържат някакво ниво на групиране и капсулиране на проблеми в отделни, независими части чрез представянето им чрез абстракции (например, функции, процедури, модули, класове, методи), които могат да бъдат използвани за изпълнение, абстрахиране и композиране на отношения. Някои отношения „пресичат“ множество абстракции в програмния код, и се наричат междусекторни отношения.

Като пример, може да се посочи „логването“ в дадена система, тъй като в зависимост от избрания вход в системата, поведението на всички методи и класове може да е различно.

Аспект наричаме единица, която капсулира дадено отношение, което пресича системните елементи в множество точки. Техниката на програмиране, която се занимава с тези дизайн проблеми се нарича Аспектно-ориентирано програмиране (АОП). Аспектно-ориентираното разработване на софтуер (АОРС) е нова технология, която се опитва да наложи АОП в масовото производство на софтуер с цел по-добро разграничение и моделиране на отношенията. Аспектите се ползват във всяка една стъпка от цикъла на производствения процес. Типични примери за аспекти са: сигурност, качество на услугата (QoS), поддръжка на трансакции, синхронизация, трасиране и т.н.

Достъп на данни

[редактиране | редактиране на кода]

Така наречените Spring frameworks за достъп на данни се отнасят за често срещани проблеми при работа с база данни, които разработчиците срещат. Както следват всички най-известни frameworks за достъп на данни в Java се поддържат: JDBC, iBatis/MyBatis, Hibernate, JDO, JPA, Oracle TopLink, Apache OJB, и Apache Cayenne и други.

За всички изброени дотук frameworks, Spring поддържа следните характеристики:

  • Resource management – Автоматично поискване и получаване на ресурси от базата данни;
  • Exception handling – превежда уникалните данните за достъп в Spring йерархия;
  • Transaction participation – прозрачно участие в настоящи трансакции;
  • Resource unwrapping – извличане на база данни обекти от pool wrappers към който е свързан;
  • Abstraction – абстракция за BLOB и CLOB манипулации.

Всички тези възможности са достъпни когато се използват шаблонни класове (template classes) предоставени за всеки framework който Spring поддържа. Критиците казват, че тези шаблонни класове са натрапчиви и не предлагат предимства пред използването примерно на Hibernate API directly. В отговор на това, разработчиците на Spring направиха възможно използването на Hibernate и JPA APIs directly. Това от своя стана изисква използването на управление на прозрачни трансакции, тъй като кода на приложението вече не поддържа свойството за получаване и затваряне на ресурси от базата данни, и не поддържа уникални трансакции.

Заедно с управлението на Spring's трансакции, този framework предлага гъвкава абстракция за работа с frameworks за достъп на данни. Spring Framework не предлага стандартен API достъп на данни; вместо това цялата мощ на поддържащото API е оставена непокътната. Spring Framework е единствения framework достъпен за Java, който предлага управление на достъпа до данните извън сървъра или контейнера на приложението.

При използването на Spring за управление на трансакциите с Hibernate, най-вероятно следните продукти ще трябва да се конфигурират:

Други стъпки от конфигурирането включват както следва:

  • AOP конфигуриране на срязващи точки (cutting points);
  • Семантика на трансакциите от AOP.

Управление на трансакциите

[редактиране | редактиране на кода]

Управление на трансакциите видове:

  • Глобални global
  • Локални local
  • Вложени nested

Глобалната поддръжка на операциите/трансакциите е една от многото причини да се използва Spring Transaction management framework. The Spring Framework предоставя последователна абстракция за управление на операциите/трансакциите, която осигурява следните предимства:

  • Последователно програмен модел в различни по операции/трансакции API-та като Java Transaction API (JTA), JDBC, Hibernate, Java Presistence API (JPA) и Java Data Objects (JDO).
  • Поддръжката за декларативно управление на трансакциите/операциите.
  • Опростени API-та за програмно управление на операциите/трансакциите от сложна трансакция като JTA
  • Отлична интеграция с Spring's data достъп абстракции.

Конфигурации на управлението на трансакциите:

  • JDBC

<bean id = “transactionManager” class = “org.springframework.jdbc.datasource.DateSourceTransactionManager”> <propertyname = “dateSource” ref = “dataSource”/> </bean>

  • Hibernate

<bean id = “transactionManager” class = “org.springframework.orm.hibernate3.HibernateTransactionManager”> <propertyname = “sessionFactory ref = “sessionFactory”/> </bean>

Platform Transaction Manager мениджъра на трансакциите включва:

  • Шаблон на трансакция template
  • Метаданни или Java анотации

Мениджъра на трансакциите е част от приложение, което отговаря за координирането на операциите/трансакциите през един или повече ресурси. В Spring framework мениджърът на трансакциите е ефективно в основата на системата на операциите.

Отговорностите на мениджъра на трансакции са следните:

Разграничаване – започващи и завършващи операции, използвайки begin, commit, and rollback методи.

Управление на контекста на трансакцията – контекст на трансакцията съдържа информацията, от която мениджър на трансакциите се нуждае, за да продължи следенето на трансакцията/операцията. Мениджъра на трансакциите е отговорен за създаването на контекст операцията и закрепването му към текущата нишка.

Координиране на трансакциите през множество ресурси – трансакциите от корпоративно ниво обикновено имат способността да координират операции от множество ресурси. Тази функция изисква 2-phase commit protocol и ресурсите трябва да бъдат регистрирани и управлявани посредством протокола XA и Open XA стандарта.

Recovery from failure – мениджъра е отговорен за осигуряване на средствата да не се оставят трансакциите в състояния на несъответствия, ако има повреда в системата и приложението се срива.[2]

Модел-Изглед-Контролер

[редактиране | редактиране на кода]

Model-View-Controller (MVC) е архитектурен модел за изграждане на потребителски интерфейси. Той разделя дадено софтуерно приложение на три взаимносвързани части, така че да се отделят вътрешни представяния на информация от начините, по които информацията се представя на потребителя/или от страна на потребителя: контролери, изгледи, модели. Както и при други софтуерни модели, MVC изразява „core of the solution“ на проблем, докато позволява да бъде адаптиран за всяка система. Специфични MVC архитектури могат да се различават значително.

Елементи: Централният елемент на MVC – The model моделът, улавя поведението на приложението по отношение на своя домейн, независимо от потребителския интерфейс. Моделът директно управлява данните, логиката и правилата на приложението. The view изгледът може да бъде всеки изход за представяне на информация, например чрез графика или диаграма; множество изгледи към една и съща информация са възможни, като стълбчета за управление и табличен изглед за счетоводители.

Третата част Controller контролера, приема входа от потребителя и го конвертира в команди за модела или изгледа.

Взаимодействия: В допълнение за разделяне на приложението на трите вида елементи, дизайн на model–view–controller определя взаимодействието между тях. The Controller – Контролерът може да изпраща команди към модела за актуализиране състоянието на модела (например, редактирането на документ). Той също може да изпраща команди към свързаната с изгледа част, за да се промени представянето на модела (например, чрез скролиране на документа).

The model – Моделът уведомява свързаните части с изгледа и контролера, когато е налице промяна в състоянието му. Това уведомяване позволява на изгледа да изведе на изхода актуалната информация и контролера да променя разположението на наборите от команди.

The view – Изгледа изисква информация от модела, който използва, за да се генерира изходната информация за представяне на потребителя.

Използване в уеб приложения: Въпреки че първоначално е разработен за настолните компютри Model-View-Controller е широко приет като архитектура за World Wide Web приложения в голяма част от езици за програмиране. Няколко търговски и нетърговски уеб приложения са създадени, които прилагат тази схемата. Тези приложения се различават по своите интерпретации, основно в начина, по който отговорностите им Model-View-Controller са разделени между клиента и сървъра.

По рано уеб MVC рамките поведоха с подход, който оставя почти цялата логика модел, изглед и контролер на сървъра. При този подход, клиентът изпраща или хипервръзки искания или форма вход към контролера и след това получава пълна и актуализирана уеб страница (или друг документ) от гледката; The model – модела съществува изцяло на сървъра.

Като клиентски технологии са създадени, рамки като AngularJS and Ember.js, JavaScriptMVC and Backbone са създадени за да позволят на елементите на MVC да изпълняват частично на машината на клиента.

История: MVC е едно от основните прозрения в началото на развитието на графични потребителски интерфейси, и един от първите подходи за описание и прилагане на софтуерни конструкции по отношение на техните отговорности. Trygve Reenskaug представя MVC в Smalltalk-76 по време на посещението на Xerox Parc през 1970 г.

През 1980, Jim Althoff и други приложени версия на MVC за Smalltalk-80 клас библиотеката. Едва по-късно, през 1988 г. в статия на списанието The Journal of Object Technology се подчертава, че MVC е изразена като основна идея в структурата на графично потребителският интерфейс.[3][4][5]

Отдалечен достъп

[редактиране | редактиране на кода]

Spring's Remote Access framework е абстракция за работа с различни RPC – базирани технологии и е достъпен на Java платформата, както за свързаност на клиенти така и за разпределителни обекти на сървъри. Най-важната особеност, предлагана от този framework е лесната конфигурация и използване на тези технологии, колкото е възможно чрез комбиниране на инверсия на контрола и аспектно ориентираното програмиране AOP.

Този framework предвижда също пълно възстановяване при неизправности (автоматично повторно свързване след неуспешна връзка) и някои оптимизации за клиентската страна при използване на EJB remote stateless session beans. Spring осигурява поддръжка за тези протоколи и продукти от кутията:

  • HTTP – базирани протоколи
  1. Hessian – двоичен сериализационен протокол, с отворен код и се поддържа от CORBA – базирани протоколи
  2. RMI (1) – метод за извиквания използващи (RMI) инфраструктура все още са специфични за Spring
  3. RMI (2) – метод за извиквания използващи (RMI) интерфейси, съобразени с редовна употреба на RMI
  4. Елемент от номериран списък RMI-IIOP (CORBA) – метод за извиквания използващи RMI-IIOP / CORBA
  • Интеграция на Enterprise JavaBean клиент
  1. Локални EJB stateless session bean connectivity – свързване с локалните stateless session beans
  2. С отдалечен достъп EJB stateless session bean connectivity – свързване с remote stateless session beans
  • SOAP Протокол за улеснен достъп до обекти
  1. Интеграция с Apache Axis Web services framework

Apache CXF осигурява интеграция със Spring framework за RPC стил за изваждане на обект от страна на сървъра.

Клиентските и сървърните настройки за всички протоколи RPC стил и продукти, поддържани от Spring Remote access framework (с изключение на поддръжката от страна на Apache Axis) са конфигурирани в Spring Core container.

Има алтернативно изпълнение с отворен код (Cluster4Spring) от подсистема за отдалечен достъп, включени в Spring framework която има за цел да подкрепи различни схеми за отдалечен достъп като (1 – 1, 1-many, dynamic services discovering).

Партиди

[редактиране | редактиране на кода]

Spring Batch framework е цялостно решение с цел да даде възможност за разработването на надеждни batch приложения, които често се срещат в съвременните enterprise системи. Spring Batch предоставя преизползваеми функции, които са от съществено значение при обработката на големи обеми от данни, включително:

  • логване/проследяване;
  • управление на трансакции;
  • статистиката за обработените задачи;
  • рестарт на задачи;
  • пропускане;
  • управление на ресурсите.

Spring Batch framework предоставя също и по-усъвършенствани технически услуги и функции, които дават възможност за обработка на изключително голям обем от данни и висока производителност на batch задачите, чрез оптимизация и подразделения.

Интеграция

[редактиране | редактиране на кода]

Spring Integration framework е framework с отворен код за интеграция на Enterprise приложения. Той предоставя възможност за разработването на интеграционни решения, типични за event-driven архитектури и messaging-centric архитектури.

  • рутери;
  • трансформатори;
  • адаптери за интегриране с други технологии и системи (HTTP, AMQP, JMS, XMPP, SMTP, IMAP, FTP (както и FTPS/SFTP), файлови системи и др.)

Spring Integration предлага също поддръжка на pipe & filter архитектури.

Източници

[редактиране | редактиране на кода]
  1. ↑ spring.io // Архивиран от оригинала на 2015-04-18. Посетен на 2015-04-20.
  2. ↑ access.redhat.com, архив на оригинала от 25 март 2016, https://web.archive.org/web/20160325160416/https://access.redhat.com/documentation/en-US/Fuse_ESB_Enterprise/7.1/html/EIP_Transaction_Guide/files/TxnManagers-WhatIs.html, посетен на 26 април 2015 
  3. ↑ whatis.techtarget.com
  4. ↑ www.yiiframework.com
  5. ↑ www.w3schools.com, архив на оригинала от 24 април 2015, https://web.archive.org/web/20150424221011/http://www.w3schools.com/aspnet/mvc_intro.asp, посетен на 26 април 2015 
  Тази страница частично или изцяло представлява превод на страницата Spring Framework в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите. ​

ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.​

Взето от „https://bg.wikipedia.org/w/index.php?title=Spring_Framework&oldid=12001655“.